Versioning Your API

APIs, SDKs, and code libraries require versioning information to allow for changes and updates to software that other systems depend upon without creating chaos or breaking production systems.

If you are using ValkyrAI or ThorAPI, you are now an API and library publisher, and you are going to have to be cognizant of this requirement and handle the publishing of your changes accordingly.

While versioning is outside of the scope of this README, we follow the traditional SEMVER best practices as much as possible.

ROADMAP: automatic SEMVER / changelog feed service

Non-Breaking Changes (increment minor versions) These are changes that ADD detail to your OpenAPI spec, such as putting a description on a property or enhancing the example for a property.

In general, these types of changes will not break or cause problems in existing applications as long as there are no unintended side effects to making the changes (such as memory usage ballooning causing OOME).

Breaking Changes

If you change the name of Objects or their properties, remove or change objects or properties, or truncate the size of or data precision of existing database columns, you will need to change the major version of your API to allow existing applications to continue using the older versions of your code.

When you increment the major version/update endpoint version, you now have 2 APIs to manage, which is why it is important to have migration plans for API consumers as well as detailed usage statistics to determine when it is safe to deprecate and remove old running API code.